Detecting and preventing flooding attacks in a network environment

ABSTRACT

A method for processing network traffic data includes receiving a packet, and determining whether the packet is a previously dropped packet that is being retransmitted. A method for processing network traffic content includes receiving a plurality of headers, the plurality of headers having respective first field values, and determining whether the first field values of the respective headers form a first prescribed pattern. A method for processing network traffic content includes receiving a plurality of packets, and determining an existence of a flooding attack without tracking each of the plurality of packets with a SYN bit.

RELATED APPLICATION DATA

This application claims the benefit as a continuation of U.S.application Ser. No. 15/055,995, filed on Feb. 29, 2016, which is acontinuation of U.S. application Ser. No. 14/692,707, filed on Apr. 21,2015, which is a continuation of U.S. application Ser. No. 14/067,575,filed on Oct. 30, 2013, and issued as U.S. Pat. No. 9,049,220 on Jun. 2,2015, which is a continuation of U.S. application Ser. No. 13/795,429,filed on Mar. 12, 2013, and issued as U.S. Pat. No. 9,130,978, which isa continuation of U.S. application Ser. No. 13/670,585, filed on Nov. 7,2012, and issued as U.S. Pat. No. 8,917,725 on Dec. 23, 2014, which is acontinuation of U.S. application Ser. No. 12/640,985, filed on Dec. 17,2009, and issued as U.S. Pat. No. 8,347,385 on Jan. 1, 2013, which iscontinuation of U.S. application Ser. No. 12/566,371, filed on Sep. 24,2009, and issued as U.S. Pat. No. 8,301,802 on Oct. 30, 2012, which is acontinuation of U.S. application Ser. No. 11/176,494, filed on Jul. 6,2005, and issued as issued as U.S. Pat. No. 7,609,625 on Oct. 27, 2009,to each of which priority is claimed and each of which are incorporatedherein by reference in their entirety.

FIELD OF THE INVENTION

The field of the invention relates to computer systems and computernetworks, and more particularly, to systems and methods for detectingand preventing flooding attacks in a network environment.

BACKGROUND

Flooding attack is a type of computer/network intrusion in which theattacker causes a high volume of sessions/connections to be createdagainst a receiver, thereby “flooding” the computer/network of thereceiver. Examples of flooding attacks include TCP flooding attacks(such as SYN flooding attacks), UDP flooding attacks, and ICMP floodingattacks. A SYN flooding attack is a connection based attack that usesTCP packets to attack a network (or a part of a network, such as afirewall), thereby overflowing session tables and/or exhaustingavailable bandwidth. UDP flooding attack and ICMP flooding attack arenon-connection based attacks, which are carried out by overflowingvirtual session tables and/or exhausting available bandwidth.

For TCP connection, the traditional SYN proxy prevention techniqueinvolves tracking each received SYN packet, regardless of whether itbelongs to flooding traffic or legitimate traffic, thereby requiring atremendous amount of system resources, such as memory, CPU cycles,storage space, and processing time. Some conventional floodingprevention devices are configured to transmit a SYN-ACK packet inresponse to a received SYN packet, acknowledging to a sender of the SYNpacket that the SYN packet has been received. Such is performed forevery SYN packet, regardless of whether the sender is a legitimate useror an attacker. These flooding prevention devices require a lot ofmemory and system resources in order to keep track with the received SYNpackets and the SYN-ACK packets. If a flooding attack is relativelyheavy, the system resources of the prevention device could be exhaustedby the flooding attack. In some cases, the additional SYN-ACK packetfrom the prevention device may double the flooding traffic, therebycausing legitimate traffic to be dropped even at link layer.

SUMMARY

In accordance to some embodiments, a method for processing networktraffic data includes receiving a packet, and determining whether thepacket is a previously dropped packet that is being retransmitted.

In accordance to other embodiments, a system for processing networktraffic data includes means for receiving a packet, and means fordetermining whether the packet is a previously dropped packet that isbeing retransmitted.

In accordance to other embodiments, a computer product includes acomputer-readable medium, the computer-readable medium having a set ofstored instructions, an execution of which causes a process to beperformed, the process comprising receiving a packet, and determiningwhether the packet is a previously dropped packet that is beingretransmitted.

In accordance to other embodiments, a method for processing networktraffic content includes receiving a plurality of headers, the pluralityof headers having respective first field values, and determining whetherthe first field values of the respective headers form a first prescribedpattern.

In accordance to other embodiments, a system for processing networktraffic content includes means for receiving a plurality of headers, theplurality of headers having respective first field values, and means fordetermining whether the first field values of the respective headersform a first prescribed pattern.

In accordance to other embodiments, a computer product includes acomputer-readable medium, the computer-readable medium having a set ofstored instructions, an execution of which causes a process to beperformed, the process comprising receiving a plurality of headers, theplurality of headers having respective first field values, anddetermining whether the first field values of the respective headersform a first prescribed pattern.

In accordance to other embodiments, a method for processing networktraffic content includes receiving a plurality of packets, anddetermining an existence of a flooding attack without tracking each ofthe plurality of packets.

In accordance to other embodiments, a system for processing networktraffic content includes means for receiving a plurality of packets, andmeans for determining an existence of a flooding attack without trackingeach of the plurality of packets.

In accordance to other embodiments, a computer product includes acomputer-readable medium, the computer-readable medium having a set ofstored instructions, an execution of which causes a process to beperformed, the process comprising receiving a plurality of packets, anddetermining an existence of a flooding attack without tracking each ofthe plurality of packets.

Other aspects and features will be evident from reading the followingdetailed description of the preferred embodiments, which are intended toillustrate, not limit, the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings illustrate the design and utility of various embodiments,in which similar elements are referred to by common reference numerals.More particular descriptions will be rendered by reference to specificembodiments, which are illustrated in the accompanying drawings.Understanding that these drawings are not to be considered limiting inscope, the embodiments will be described and explained with additionalspecificity and detail through the use of the accompanying figures.

FIG. 1 illustrates a block diagram representing a system that includes amodule for processing network traffic data in accordance with someembodiments;

FIG. 2 illustrates a method for processing network traffic data inaccordance with some embodiments;

FIG. 2A illustrates a method of carrying out a step of the method ofFIG. 2 in accordance with some embodiments;

FIG. 3 illustrates a method for processing network traffic data inaccordance with other embodiments;

FIG. 4 illustrates a method for processing network traffic data inaccordance with other embodiments;

FIG. 5 illustrates a method for processing network traffic data inaccordance with other embodiments;

FIG. 6A illustrates an example of an IP header that can be analyzedusing module of FIG. 1;

FIG. 6B illustrates an example of a rep header that can. be analyzedhousing module of FIG. 1; and

FIG. 7 is a diagram of a computer hardware system with which embodimentsdescribed herein can be implemented.

DETAILED DESCRIPTION

Various embodiments are described hereinafter with reference to thefigures. It should be noted that the figures are not drawn to scale andthat elements of similar structures or functions are represented by likereference numerals throughout the figures. It should also be noted thatthe figures are only intended to facilitate the description of specificembodiments, and are not intended as an exhaustive description of theinvention, or as a limitation on the scope of the invention. Inaddition, an illustrated embodiment need not have all the aspects oradvantages shown. An aspect or an advantage described in conjunctionwith a particular embodiment is not necessarily limited to thatembodiment and can be practiced in any other embodiments even if not soillustrated.

FIG. 1 illustrates a block diagram of a system 2, which includes amodule 10 for processing network traffic data in accordance with someembodiments. Module 10 is communicatively coupled between sender 12 andreceiver 13. However, in other embodiments, module 10 can be a part of,or be integrated with, sender 12, receiver 13, or both. During use,sender 12 transmits data (packet) to module 10. Module 10 receives thetransmitted data, and determines whether the packet is associated with aflooding attack. In some embodiments, the packet received by module 10is a SYN packet, which is used to create a session/connection. In otherembodiments, the packet received by module 10 can by other types ofpacket. As used in this specification, the term “sender” should not belimited to a human, and can include a server or other types of devices(software and/or hardware) that can receive and/or transmit information.Also, as used in this specification, the term “receiver” should not belimited to a human receiver, and can include a server or other types ofdevices (software and/or hardware) that can store, receive, and/ortransmit information.

In some embodiments, module 10 can be implemented using software. Forexample, module 10 can be implemented using software that is loaded ontoa user's computer, a server, or other types of memory, such as a disk ora CD-ROM. In some cases, module 10 can be implemented as webapplications. In alternative embodiments, module 10 can be implementedusing hardware. For example, in some embodiments, module 10 includes anapplication-specific integrated circuit (ASIC), such as a semi-customASIC processor or a programmable ASIC processor. ASICs, such as thosedescribed in Application—Specific Integrated Circuits by Michael J. S.Smith, Addison-Wesley Pub Co. (1st Edition, June 1997), are well knownin the art of circuit design, and therefore will not be described infurther detail herein. In other embodiments, module 10 can also be anyof a variety of circuits or devices that are capable of performing thefunctions described herein. For example, in alternative embodiments,module 10 can include a general purpose processor, such as a Pentiumprocessor. In other embodiments, module 10 can be implemented using acombination of software and hardware. In some embodiments, module 10 maybe implemented as a firewall, a component of a firewall, or a componentthat is configured to be coupled to a firewall. In other embodiments,module 10 is implemented as a component of a gateway 12 (or gatewayproduct, such as an anti-virus module). In further embodiments, insteadof being a component of gateway 12, module 10 can be a separatecomponent that is coupled to gateway 12. In other embodiments, module 10can be a gateway product by itself, and can be implemented at any pointalong a communication path between sender 12 and receiver 13. In furtherembodiments, module 10 could be used in a switch, such as a securityswitch.

FIG. 2 illustrates a method 20 for processing network traffic data usingmodule 10 in accordance with some embodiments. First, module 10 receivesnetwork traffic data (packet) from sender 12 (Step 22). In theillustrated embodiments, the network traffic data is a packet used in aprocess for establishing a connection, transmitting data, or shutdown aconnection. For example, the received data can be a TCP packet (such asa SYN packet) that includes a TCP header. However, the received data canbe other types of packet in other embodiments.

Module 10 next updates a concurrent session counter N, which representsa number of sessions being processed at a gateway (e.g., at module 10)(Step 24). In some embodiments, the concurrent session counter Nrepresents a number of sessions that are transmitted from one or moresender(s) (or host(s)). In such cases, different concurrent sessioncounters Ni can each be used to keep track with the number of sessionsfrom a different sender or from a different group of senders. In otherembodiments, the concurrent session counter N represents a number ofsessions that are targeted against one or more receiver(s) (e.g., awebsite). In such cases, different concurrent session counters Ni caneach be used to keep track with the number of sessions targeted againsta different receiver or against a different group of receivers. In otherembodiments, the concurrent. For example, module 10 can update theconcurrent session counter N by incrementing the value N by one. In theillustrated embodiments, a storage device can be used for storing theconcurrent session counter. The storage device can be a disk, a computerhard drive, a server, a memory, or any device capable of storingelectronic information. Such storage device can be a component of module10, a component that is configured to integrate with module 10, or acomponent that is coupled to module 10 via a communication link (wire orwireless).

Next, module 10 compares the concurrent session counter N with aprescribed concurrent session threshold T1 (Step 26). If the concurrentsession counter N is less than the prescribed concurrent sessionthreshold T1, the network traffic data is determined not to beassociated with a flooding attack. In such cases, module 10 then passesthe network traffic data downstream (Step 28). In some embodiments,module 10 passes the network traffic data to receiver 13. In otherembodiments, module 10 passes the network traffic data to another moduleor processing unit for further processing the network traffic data. Forexample, module 10 can pass the network traffic data to a policyenforcement module (not shown), which performs policy enforcement on thetraffic data before passing it onto receiver 13. As another example,module 10 can pass the network traffic data to a content detectionmodule (not shown), which determine whether the network traffic data isan undesirable content, such as a virus, a worm, a Trojan horse, etc. Inother embodiments, data received from sender 12 is transmitted to policyenforcement module which performs policy enforcement on the receiveddata before the received data is passed to module 10 for floodingdetection.

If the concurrent session counter N is greater than or equal to theprescribed concurrent session threshold T1, then module 10 performsadditional process to determine if the received packet is associatedwith a flooding attack (Step 30). In the illustrated embodiments, if thereceived packet is connection-based (having protocol that includes aretransmission mechanism), module 10 uses a retransmission featureassociated with the received packet to determine whether the receivedpacket is associated with a flooding attack (FIG. 2A). In such cases, ifthe concurrent session counter N is greater than or equal to theprescribed concurrent session threshold T1, module 10 then determineswhether the received packet is a newly received packet (i.e., one thathas not been received previously) (Step 34). For example, module 10 candetermine whether the received packet is a newly received packet byusing a log that records previously received packets. In such cases,module 10 compares the received packet with records in the log, anddetermines whether the received packet is a newly received packet (if nomatch is found in the log) or a retransmitted packet (if a match isfound in the log). In some embodiments, a hash table (an example of alog) can be used by module 10 to keep track of previously receivedrecords. Such technique is beneficial in that it obviates the need tosave all previously received packets, thereby saving memory.

If the received packet is a newly received packet, module 10 then dropsthe packet, regardless of whether the packet is in fact associated witha flooding attack or not (Step 32). Since an authentic packet (one thatis not associated with a flooding attack) will always be retransmittedafter it is dropped, if the packet dropped by module 10 is authentic,the dropped packet will be retransmitted to the module 10. If thedropped packet is one that is associated with a flooding attack, it maynot be retransmitted to module 10, at least not within a prescribedperiod.

In some embodiments, in addition to determining whether there is a matchbetween the currently received packet and a record in the log, module 10also determines whether the packet is being transmitted within aprescribed period from a transmission time associated with a record inthe log (e.g., by comparing the transmission time of the current packetwith the transmission time associated with a record in the log). Thetransmission time comparison can be performed before or after thereceived packet is compared with the log records to determine if thereis a match. If the current packet is received within a prescribed time(e.g., one minute, one hour, one day, etc.) from the transmission timeof a matched record in the log, then the received packet is determinednot to be associated with a flooding attack. This technique is based onthe fact that an authentic packet will usually be retransmitted within acertain time period. In some embodiments, received packet and/or droppedpacket is time-stamped, and a hash table can be used to organizeinformation about these packets. It should be noted that the term“transmission time” (or “retransmission time”) can be a time in which apacket is transmitted by a sender, or alternatively, a time in which apacket is received by module 10.

In other embodiments, instead of, or in addition to, using the abovedescribed techniques, module 10 can be configured to determine whether areceived packet is a retransmitted packet based on a protocol definitionstandard, such as RFC 793 (for TCP). For example, if a protocol,definition standard requires a retransmitted packet to havecharacteristic “X,” module 10 can then determine whether a receivedpacket has characteristic “X” to decide whether the received packet is aretransmitted packet.

If module 10 determines that the received packet is a retransmittedpacket within a prescribed period from its last transmission (indicatingthat the received packet is an authentic packet), module 10 then passesthe data downstream (Step 28). On the other hand, if module 10determines that the received packet is not a retransmission, module 10then drops the packet (Step 32). In some embodiments, module 10 alsoterminates the session associated with the packet. After module 10terminates a session, module 10 updates the concurrent session counter Nby decrementing the value N by one. As such, the concurrent sessioncounter N keeps track with a number of sessions that are being processedat a given time.

In the illustrated embodiments, different concurrent session thresholdsT1,n are assigned for processing different types of received data. Insome embodiments, TCP packets for different websites can be consideredto be of different types. For example, a first concurrent sessionthreshold T1,1 can be assigned for processing SYN packet (an example ofa TCP packet) associated with a first receiver IP address (e.g., a YahooIP address), and a second concurrent session threshold T1,2 can beassigned for processing SYN packet associated with a second receiver IPaddress (e.g., a Google IP address). During use, module 10 determinesthe type of received data (e.g., SYN packet for a particular IPaddress), and applies the prescribed concurrent session threshold T1 forthe prescribed type of data when performing step 44. In otherembodiments, a concurrent session threshold T1 can be assigned forprocessing multiple types of received data (e.g., SYN packet associatedwith a plurality of receiver IP addresses).

In other embodiments, packets created in different times during the daycan be considered to be of different types. For example, a firstconcurrent session threshold T1,1 can be assigned for processing SYNpacket created during a first time period (e.g., between 8:00 am to 5:00pm), and a second concurrent session threshold T1,2 can be assigned forprocessing SYN packet created during a second time period (e.g., between5:00 pm to 8:00 am). During use, module determines the time at which thereceived packet is created (e.g., using a timestamp), and applies theprescribed concurrent session threshold T1 for the prescribed type ofpacket when performing step 26. In other embodiments, a concurrentsession threshold T1 can be assigned for processing received packetsregardless of when they are created.

In the illustrated embodiments, the concurrent session threshold T1 isdetermined and input by an administrator. In other embodiments, module10 can be configured to have a learning feature in which module 10determines the concurrent session threshold T1 for a prescribed type ofpacket based on previously received packet having the same type. Forexample, based on a history log, module 10 can determine that an IPaddress tends to have more sessions than others, and therefore, assignsa higher concurrent session threshold T1 value for the IP address. Asanother example, based on a history log, module 10 can determine that anIP address tends to have more sessions during a particular time periodin the day, and therefore, assigns a higher concurrent session value forthe IP address at that time period. As such, different concurrentsession thresholds T1 can be assigned for different IP addresses and/ortime periods. In some embodiments, a user interface can be provided thatallows a user to input the concurrent session threshold T1, or toprescribe criteria or parameters for allowing module 10 to determine theconcurrent session threshold T1 for each data type.

As illustrated in the above embodiments, using a concurrent sessioncounter to keep track with a number of sessions is advantageous in thatthe concurrent session counter can be used to detect a flooding attack.This is possible because in a flooding attack, many sessions (e.g.,hundreds or thousands of sessions) may be generated by the attacker. Assuch, if a number of concurrent sessions is above the prescribedthreshold T1, it is likely that a flooding attack is occurring.

It should be noted that although embodiments of method 20 have beendescribed, the scope of the invention should not be so limited. In otherembodiments, method 20 can have order of steps that is different fromthat described previously. For example, in some embodiments, module 10can update the concurrent session counter after step 26. Also, in otherembodiments, module 10 does not perform steps 24 and 26 of method 20. Infurther embodiments, any combination of the steps of method 20 can becarried out before or after policy enforcement is performed on thereceived data. In addition, in other embodiments, instead of using aretransmission feature to detect a flooding attack, module 10 can beconfigured to perform other technique(s) known in the art to determinewhether the received packet is associated with a flooding attack.

Although method 20 has been described with reference to the concurrentsession counter N, in other embodiments, other types of counter may beused. FIG. 3 illustrates a method 40 for processing network traffic datausing module 10 in accordance with other embodiments, wherein a sessionrate R (a rate-based counter) is used instead of the concurrent sessioncounter N. First, module 10 receives data from sender 12 (Step 22). Inthe illustrated embodiments, the network traffic data is a packet usedin a process for establishing a connection, transmitting data, orshutdown a connection. For example, the received data can be a TCPpacket that includes a TCP header. However, the received data can beother types of packet in other embodiments.

Module 10 next updates a session rate R, which represents a number ofsessions that are received within a time period, such as one second(Step 42). For example, module 10 can be configured to update thesession rate R by determining a number n of sessions being receivedwithin a time period t, and dividing the number n by t (Le., R=n/t). Insome cases, the session rate R represents a number of requests sent toreceiver 13 within a prescribed period t. In the illustratedembodiments, a storage device can be used for storing the session rateR. The storage device can be a disk, a computer hard drive, a server, amemory, or any device capable of storing electronic information. Suchstorage device can be a component of module 10, a component that isconfigured to integrate with module 10, or a component that is coupledto module 10 via a communication link (wire or wireless).

Next, module 10 compares the session rate R with a prescribed sessionrate threshold T2 (Step 44). If the session rate R is less than theprescribed session rate threshold T2, the network traffic data isdetermined not to be associated with a flooding attack. In such cases,module 10 then passes the network traffic data downstream (Step 28), assimilarly discussed with reference to method 20.

If the session rate R is greater than or equal to the prescribed sessionrate threshold T2, then module 10 performs additional process todetermine if the received data is associated with a flooding attack(Step 30), as similarly discussed with reference to method 20. If module10 determines that the received data is not associated with a floodingattack, module 10 then passes the data downstream (Step 28). Otherwise,module 10 drops 32 the packet (Step 32).

In the illustrated embodiments, different session rate thresholds T2,nare assigned for processing different types of received packet. In someembodiments, TCP packets for different websites can be considered to beof different types. For example, a first session rate threshold T2,1 canbe assigned for processing SYN packet (an example of a TCP packet)associated with a first receiver IP address (e.g., a Yahoo IP address),and a second session rate threshold T2,2 can be assigned for processingSYN packet associated with a second receiver IP address (e.g., a GoogleIP address). During use, module 10 determines the type of receivedpacket (e.g., SYN packet for a particular IP address), and applies theprescribed session rate threshold T2 for the prescribed type of packetwhen performing step 44. In other embodiments, a session rate thresholdT2 can be assigned for processing multiple types of received packet(e.g., SYN packet associated with a plurality of receiver IP addresses).

In other embodiments, packets created in different times during the daycan be considered to be of different types. For example, a first sessionrate threshold T2,1 can be assigned for processing SYN packet createdduring a first time period (e.g., between 8:00 am to 5:00 pm), and asecond session rate threshold T2,2 can be assigned for processing SYNpacket created during a second time period (e.g., between 5:00 pm to8:00 am). During use, module 10 determines the time at which thereceived packet is created (e.g., using a timestamp), and applies theprescribed session rate threshold T2 for the prescribed type of packetwhen performing step 44. In other embodiments, a session rate thresholdT2 can be assigned for processing received packets regardless of whenthey are created.

In the illustrated embodiments, the session rate threshold T2 isdetermined and input by an administrator. In other embodiments, module10 can have and learning feature in which module 10 determines thesession rate threshold T2 for a prescribed type of packet based onpreviously received packet having the same type. For example, based on ahistory log, module 10 can determine that an IP address tends to have ahigher session rate than others, and therefore, assigns a higher sessionrate threshold T2 value for the IP address. As another example, based ona history log, module 10 can determine that an IP address tends to havea higher session rate during a particular time period in the day, andtherefore, assigns a higher session rate threshold T2 for the IP addressat that time period. As such, different session rate thresholds T2 canbe assigned for different IP addresses and/or time periods. In someembodiments, a user interface can be provided that allows a user toinput the session rate threshold T2, or to prescribe criteria orparameters for allowing module 10 to determine the session ratethreshold T2 for each data type.

Using the session rate R to keep track with a number of sessions beingprocessed per time period is advantageous in that the session rate R canbe used to detect a flooding attack. This is possible because in aflooding attack, many sessions (e.g., hundreds or thousands of sessions)may be received within a time period. As such, if a number of sessionsreceived within a prescribed time period is above the prescribed sessionrate threshold T2, it is likely that a flooding attack is occurring.

It should be noted that although embodiments of method 40 have beendescribed, the scope of the invention should not be so limited. In otherembodiments, method 40 can have order of steps that is different fromthat described previously. For example, in some embodiments, module 10can update the session rate R after step 44 . . Also, in otherembodiments, module 10 does not perform steps 42 and 44, of method 40.In further embodiments, any combination of the steps of method 40 can becarried out before or after policy enforcement is performed on thereceived packet. In addition, in other embodiments, instead of using aretransmission feature to determine whether a received packet isassociated with a flooding attack, module 10 can be configured toperform other technique(s) known in the art to determine whether thereceived data is associated with a flooding attack.

In other embodiments, module 10 may be configured to use both theconcurrent session counter N and the session rate R. FIG. 4 illustratesa method 50 for processing network traffic data using module 10 inaccordance with other embodiments. First, module 10 receives data fromsender 12 (Step 22). Next, module 10 updates the concurrent sessioncounter N (Step 24), and compares the updated concurrent session counterN against the prescribed concurrent session threshold T1 (Step 26). Ifthe concurrent session counter N is less than the prescribed concurrentsession threshold T1, the network traffic data is determined not to beassociated with a flooding attack. In such cases, module 10 then passesthe network traffic data downstream (Step 28). Steps 24, 26 are similarto those discussed with reference to FIG. 2.

If the concurrent session counter N is larger than or greater than theprescribed concurrent session threshold T1, module 10 then updates asession rate R (a rate-based counter), which represents a number ofsessions that are received within a time period, such as one second(Step 42). Next, module 10 compares the session rate R with a prescribedsession rate threshold T2 (Step 44). Steps 42, 44 are similar to thosediscussed with reference to FIG. 3.

If the session rate R is less than the prescribed session rate thresholdT2, the network traffic data is determined not to be associated with aflooding attack. In such cases, module 10 then passes the networktraffic data downstream (Step 28).

If the session rate R is greater than or equal to the prescribed sessionrate threshold T2, then module 10 performs additional process todetermine if the received data is associated with a flooding attack(Step 30). For example, in some embodiments, module 10 can be configuredto use a retransmission feature to determine whether a received packetis associated with a flooding attack, as discussed with reference tomethod 20. If module 10 determines that the received data is notassociated with a flooding attack, module 10 then passes the datadownstream (Step 28). Otherwise, module 10 drops the packet and/orterminates the session associated with the packet (Step 32).

Using both the concurrent session counter N and the session rate R todetect flooding attack is advantageous in that the counter N can be usedas a backup for the session rate R, and vice versa, thereby providing amore reliable flooding detection. For example, in some cases, it may bepossible that a flooding attack cannot be detected using the concurrentsession counter N (e.g., because the counter N is below the prescribedthreshold T1). In such cases, the session rate R can be used as a backupdefense to detect a flooding attack. Also, in other cases, it may bepossible that a flooding attack cannot be detected using the sessionrate R (e.g., because the rate R is below the prescribed threshold T2.In such cases, the concurrent session counter N can be used as a backupdefense to detect a flooding attack.

It should be noted that although embodiments of method 50 have beendescribed, the scope of the invention should not be so limited. In otherembodiments, method 50 can have orders of steps that is different fromthat described previously. For example, in some embodiments, module 10can update the concurrent session counter N after step 26 and/or updatethe session rate R after step 44. In other embodiments, module 10 canperform step 24 before, or simultaneously with, step 42. Also, in otherembodiments, module 10 does not perform steps 24, 26, and/or steps 42and 44, of method 50. In further embodiments, any combination of thesteps of method 50 can be carried out before or after policy enforcementis performed on the received data.

FIG. 5 illustrates a method 80 for detecting a flooding attack usingmodule 10 in accordance with other embodiments. Method 80 can be used inconjunction with any of the methods described herein. For example, insome embodiments, method 80 can be performed in step 30 of method 20,40, or 50. In some embodiments, method 50 is used instead of theflooding detection technique that uses a retransmission feature of apacket (discussed herein). In other embodiments, method 80 is used inconjunction with the flooding detection technique that uses aretransmission feature of a packet, to thereby improve a floodingdetection accuracy and/or efficiency. In other embodiments, method 80can be used individually to detect flooding attack(s). Method 80 canalso be combined with other techniques known in the art to detectflooding attack(s) in other embodiments.

First, module 10 receives data (packet) from sender 12 (Step 82). In theillustrated embodiments, the received packet includes a header, such asa TCP header, an IP header, an UDP header, or an ICMP header. In otherembodiments, the received packet can include other types of header.

The received header includes one or more header fields. FIG. 6Aillustrates an example of a header data structure 60, which includes anIP protocol version field 61, an IHL field 62, a service type field 63,a length field 64, an identification field 65, a flag field 66, afragment offset field 67, a time to live field 68, a protocol field 69,a header checksum field 70, a source address field 71, a destinationaddress field 72, an option field 73, and a padding field 74.Each of theheader fields 61-74 has a field value associated therewith. FIG. 6Billustrates an example of a TCP header data structure 140, whichincludes a source port 141 field, a destination port field 142, asequence number field 143, an acknowledgment number field 144, a dataoffset field 145, a reserved field 146, flag fields 147, a window field148, a checksum field 149, an urgent pointer field 150, an option field151, and, a padding field 152. It should be noted that the receivedheader is not limited to the examples discussed previously, and thatdepending on the type of packet received, the header of the receivedpacket will have different types of header fields.

Next, module 10 examines respective one or more header fields of aplurality of received headers to determine whether the respective headerfield values of the received headers form a prescribed pattern (Step84). For example, in some embodiments, module 10 is configured tocompare a value in one of the fields 61-74 (e.g., field 61) in a firstheader, with a value in a respective field (e.g., field 61) in a secondheader, to determine if the first and second header field values form aprescribed pattern. As used in this specification, the term “prescribedpattern” refers to a pattern formed by two or more values, anidentification of which (the pattern) can be used to detect a floodingattack. Examples of a prescribed pattern include, a pattern formed bytwo or more values that are identical, two or more sequentiallyincreasing values (e.g., by a constant increment), two or moresequentially decreasing values, and two or more values having sameattributes (e.g., checksum value). In some embodiments, module 10includes a user interface that allows an administrator to select ordetermine a prescribed pattern for use to detect flooding attacks. Inthe illustrated embodiments, module 10 is configured to determine that aflooding attack is occurring when a prescribed pattern formed by headerfields in a plurality of headers is detected, and that a flooding attackis not occurring when a prescribed pattern is not detected (Step 86).

Several examples of using prescribed pattern to identify floodingattacks will now be described. In some embodiments, module 10 isconfigured to examine (e.g., determine) the sequence number with host ornetwork order associated with packets. Sequence number is a portion inTCP header. It is also called ISN (Initial Sequence Number) in SYNpacket. In the illustrated embodiments, module 10 is configured to keeptrack with the number of SYN packets having sequence number with host ornetwork order that fit within a prescribed pattern. For example, if thenumber of SYN packets (1) having the same sequence number, (2) havingsequence number with host or network order that are sequentiallyincreasing, or (3) having sequence number with host or network orderthat are sequentially decreasing, exceeds a prescribed threshold T3,such as ten, then module 10 determines that a flooding attack isoccurring. This technique is based on the fact that a sequence numberassociated with a first authentic packet is generally unrelated to (andtherefore appears random from) the sequence number associated with asecond authentic packet. Many flooding tools try to generate SYN packetsas fast as possible, and therefore, create packets having the samesequence number. Some tools increase the sequence number by one withhost order or network order. As such, if a number of packets havingsequence number appear to have a regular pattern, it is likely thatthere is a flooding attack. In other embodiments, the prescribedthreshold T3 may be more or less than ten.

Similar techniques may be used with respect to identification fieldvalue in IP header. The identification field value in IP header is usedto uniquely identify the fragments of a particular datagram. It servessimilar function as sequence number in TCP header. In some embodiments,if the number of packets having same or sequentially changed IPidentification exceeds a prescribed threshold T4, such as ten, thenmodule 10 determines that a flooding attack is occurring. In otherembodiments, the prescribed threshold T4 may be more or less than ten.

In other embodiments, module 10 is configured to examine the TCP flag inSYN packets to determine whether a flooding attack is occurring. Forexample, module 10 can be configured to keep track with the number ofpackets having CWR, ECN, PSH, or their combination, turned on. If thenumber of packets having CWR, ECN, PSH, or their combination, turned on,exceeds a prescribed threshold T5, such as ten, then module 10determines that a flooding attack is occurring. This technique is basedon the fact that many flooding tools set the same bit (e.g., a ECN bit,CWR bit, or PSH bit), or the same combination of bit (e.g., a ECN andCWR bit), in SYN packets. In other embodiments, the prescribed thresholdT5 may be more or less than ten.

In other embodiments, module 10 is configured to examine the TCP optionor the IP option associated with packets to determine if the TCP or IPoption has valid type or format. For example, if the number of packetshaving invalid type or format in the TCP or IP option exceeds aprescribed threshold T6, such as ten, then module 10 determines that aflooding attack is occurring. This technique is based on the fact thatan authentic packet generally has valid type or format associated withTCP or IP option. As such, if a number of packets having invalid type orformat associated with their TCP or IP option, it is likely that thereis a flooding attack. In other embodiments, the prescribed threshold T6may be more or less than ten. For example, in some embodiments, theprescribed threshold T6 may be set to one. In such cases, if a receivedpacket has invalid type or format in the TCP or IP option, module 10then takes preventive action (step 32) without considering whether otherpacket(s) has a similar characteristic.

In other embodiments, module 10 is configured to examine a checksum inTCP or IP header. Checksum is generally included in TCP and IP header toensure that bit stream is not damaged during transmission of packet. Assuch, checksum should be accurate in normal (non-attacking) traffic. Insome embodiments, module .10 is configured to determine whether achecksum associated with a TCP or IP header is incorrect. If thechecksum is determined to be incorrect, then module 10 determines that aflooding attack is occurring. This technique is based on the fact thatmany attackers do not take the effort to calculate the correct checksumfor each flooding packet they send. In other embodiments, instead of TCPand IP headers, module 10 can be configured to examine a checksum inother types of headers. Also, in other embodiments, instead of using achecksum value to determine whether a header is associated with aflooding attack, module 10 can use a checksum value to detect othertypes of undesirable content, such as a virus, a worm, etc.

In other embodiments, module 10 is configured to examine a IP protocolversion value in the IP protocol version field 61. For example, module10 can be configured to determine whether a IP protocol version value isvalid. If the IP protocol version value is determined to be invalid,module 10 then takes preventive action (Step 32). In other embodiments,module 10 is configured to keep track with the number of packets thathave invalid IP protocol version values. If the number of such packetsexceeds a prescribed threshold; module 10 then determines that aflooding attack is occurring.

In some cases, respective field values in two headers are not the sameand do not form a sequentially increasing or decreasing pattern, but maystill be considered related (or forming a prescribed pattern) if theycontain similar attributes. For example, in some embodiments, ifrespective checksums of field values of two header fields are the same,or are within a prescribed range, the two headers may be consideredrelated to each other (e.g., originating from a same flooding program).In other embodiments, other types of calculation or techniques can beused to determine whether two received packets are related.

It should be noted that the variables used to detect a prescribedpattern should not be limited to the examples discussed previously. Inother embodiments, instead of, or in addition to, the above variables,module 10 can be configured to detect prescribed pattern(s) form byother variables (e.g., header field values) associated with receivedpackets.

In other embodiments, one or more of the above techniques can becombined. For example, in. some embodiments, module 10 is configured toexamine both the sequence number and TCP flag of incoming packets, anddetermine whether the respective sequence numbers form a firstprescribed pattern (e.g., have identical values, sequentially increasingvalues, or sequentially decreasing values), and whether the respectiveTCP flags form a second prescribed pattern (e.g., have identical values,sequentially increasing values, or sequentially decreasing values). Insuch cases, if the sequence numbers and the TCP flags form respectivefirst and second prescribed patterns, module 10 then determines that aflooding attack is occurring.

Also, in any of the embodiments discussed herein, a prescribed timeperiod can be used when detecting a prescribed pattern among receivedheaders. For example, if two headers having sequential numbers that areidentical are received within a prescribed period (e.g., 1 minute) fromeach other, then module 10 determines that a prescribed pattern has beendetected. On the other hand, if two TCP headers having sequence numbersthat are identical are received beyond a prescribed period (e.g., 1hour, etc.) from each other, then module 10 determines that noprescribed pattern has been detected.

Regardless of the technique used, if module 10 determines that aflooding attack is occurring, module 10 then prevents packet havingfield value(s) that fall within the detected pattern from being sent toreceiver 13 (Step 88). For examples, module 10 can be configured to dropa packet, terminate a session (e.g., TCP re-sets or ICMP unreachablemessages), or send a notification to a designated receiver indicatingthat a flooding attack has been detected. In other embodiments, module10 can be configured to gather information regarding the network trafficdata that has been associated with a flooding attack. For example,module 10 can be configured to record all packets and associatedinformation generated directly or indirectly by sender 12, including butnot limited to, order, sequence, timestamps, transmission statistics,and type of packets, into a system log. Such information can be used toidentify tool, methodology being used, and intention (e.g., vandalism,data theft, remote launch point search, etc.) of sender 12. The recordedinformation can also be used to identify future flooding attacks.

If module 10 determines that no flooding attack is occurring, module 10then passes the network traffic data downstream (Step 90). In someembodiments, module 10 passes the network traffic data to receiver 13.In other embodiments, module 10 passes the network traffic data toanother module or processing unit for further processing the networktraffic data. For example, module 10 can pass the network traffic datato a policy enforcement module (not shown), which performs policyenforcement on the traffic data before passing it onto receiver 13. Asused in this specification, the term “policy enforcement” refers to aprocess or procedure, an execution of which creates a result that can beused to determine whether to pass data to user, and includes (but is notlimited to) one or a combination of: source verification, destinationverification, user authentication, virus scanning, content scanning(e.g., scanning for undesirable content), and intrusion detection (e.g.,detecting undesirable content, such as worms, porno website, etc.). Asanother example, module 10 can pass the network traffic data to acontent detection module (not shown), which determine whether thenetwork traffic data is/has an undesirable content, such as a virus, aworm, a trojan hourse, etc. Policy enforcement module and contentdetection module are known in the art. In other embodiments, datareceived from sender 12 is transmitted to policy enforcement modulewhich performs policy enforcement on the received data before thereceived data is passed to module 10 for flooding detection.

Detecting flooding attack based on identifying a prescribed pattern formby header fields of packets is advantageous in that it requiresrelatively low system resources compared to conventional techniques,such as SYN proxy to track each packet. The above described techniquealso allows flooding attack to be detected more accurately since apacket may appear legitimate by itself, but may form a pattern with oneor more other packets that are associated with a flooding attack.

It should be noted that module 10 and processes 20, 40, 50, 80 are notlimited to detecting TCP flooding attacks. In other embodiments, module10 and processes 20, 40, 50, 80 may be used to detect other connectionbased flooding attacks, in which received data is a packet used in aprocess for establishing a connection, transmitting data, or shutdown aconnection. In further embodiments, module 10 and any of the methodsdescribed herein can be used to detect non-connection based floodingattacks, such as UDP and ICMP flooding attacks. In such cases, module 10is configured to generate a virtual session such that the UDP packetsand/or the ICMP packets can be processed in the same or similar ways asthat of a TCP packet. The virtual session can be any data structure thatcorrelates packets between sender 12 and receiver 13, to thereby trackUDP and ICMP traffic. In some embodiments, module 10 includes a protocoldifferentiator (not shown), which examines headers of the networktraffic and determines the types of data being processed. Module 10 thenanalyzes traffic data using prescribed technique, depending on the typeof network traffic received.

Computer Architecture

As described previously, module 10 can be implemented using software,hardware, or combination therefore. However, those skilled in the artunderstand that a computer system may also be used to implement module10 to perform the same or similar functions described herein. FIG. 7 isa block diagram that illustrates an embodiment of a computer system 100upon which embodiments of the methods 20, 40, 50 and/or 80 may beimplemented. Computer system 100 includes a bus 102 or othercommunication mechanism for communicating information, and a processor104 coupled with bus 102 for processing information. Computer system 100also includes a main memory 106, such as a random access memory (RAM) orother dynamic storage device, coupled to bus 102 for storing informationand instructions to be executed by processor 104. Main memory 106 alsomay be used for storing temporary variables or other intermediateinformation during execution of instructions to be executed by processor104. Computer system 100 may further include a read only memory (ROM)108 or other static storage device coupled to bus 102 for storing staticinformation and instructions for processor 104. A data storage device110, such as a magnetic disk or optical disk, is provided and coupled tobus 102 for storing information and instructions.

Computer system 100 may be coupled via bus 102 to a display 112, such asa cathode ray tube (CRT), for displaying information to user 104. Aninput device 114, including alphanumeric and other keys, is coupled tobus 102 for communicating information and command selections toprocessor 104. Another type of user input device is cursor control 116,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 104 and forcontrolling cursor movement on display 112. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 100 can be used for processing network traffic data,such as a packet, a header, or a portion of a header. According to someembodiments, such use may be provided by computer system 100 in responseto processor 104 executing one or more sequences of one or moreinstructions contained in the main memory 106. Such instructions may beread into main memory 106 from another computer-readable medium, such asstorage device 110. Execution of the sequences of instructions containedin main memory 106 causes processor 104 to perform the process stepsdescribed herein. One or more processors in a multi-processingarrangement may also be employed to execute the sequences ofinstructions contained in main memory 106. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement embodiments described herein. Thus,embodiments described herein are not limited to any specific combinationof hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 104 forexecution. Such a medium may take many forms, including but not limitedto, non-volatile media, volatile media, and transmission media.Non-volatile media includes, for example, optical or magnetic disks,such as storage device 110. Volatile media includes dynamic memory, suchas main memory 106. Transmission media includes coaxial cables, copperwire and fiber optics, including the wires that comprise bus 102.Transmission media can also take the form of acoustic or light waves,such as those generated during radio wave and infrared datacommunications.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, a RAM, a PROM, and EPROM,a FLASH-EPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread.

Various forms of computer-readable media may be involved in carrying oneor more sequences of one or more instructions to processor 104 forexecution. For example, the instructions may initially be carried on amagnetic disk of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 100 canreceive the data on the telephone line and use an infrared transmitterto convert the data to an infrared signal. An infrared detector coupledto bus 102 can receive the data carried in the infrared signal and placethe data on bus 102. Bus 102 carries the data to main memory 106, fromwhich processor 104 retrieves and executes the instructions. Theinstructions received by main memory 106 may optionally be stored onstorage device 110 either before or after execution by processor104.

Computer system 100 also includes a communication interface 118 coupledto bus 102. Communication interface 118 provides a two-way datacommunication coupling to a network link 120 that is connected to alocal network 122. For example, communication interface 118 may be anintegrated services digital network (ISDN) card or a modem to provide adata communication connection to a corresponding type of telephone line.As another example, communication interface 118 may be a local areanetwork (LAN) card to provide a data communication connection to acompatible LAN. Wireless links may also be implemented. In any suchimplementation, communication interface 118 sends and receiveselectrical, electromagnetic or optical signals that carry data streamsrepresenting various types of information.

Network link 120 typically provides data communication through one ormore networks to other devices. For example, network link 120 mayprovide a connection through local network 122 to a host computer 124.Network link 120 may also transmits data between an equipment 126 andcommunication interface 118. The data streams transported over thenetwork link 120 can comprise electrical, electromagnetic or opticalsignals. The signals through the various networks and the signals onnetwork link 120 and through communication interface 118, which carrydata to and from computer system 100, are exemplary forms of carrierwaves transporting the information. Computer system 100 can sendmessages and receive data, including program code, through thenetwork(s), network link 120, and communication interface 118. Althoughone network link 120 is shown, in alternative embodiments, communicationinterface 118 can provide coupling to a plurality of network links, eachof which connected to one or more local networks. In some embodiments,computer system 100 may receive data from one network, and transmit thedata to another network. Computer system 100 may process and/or modifythe data before transmitting it to another network.

Although particular embodiments have been shown and described, it willbe understood that it is not intended to limit the present inventions tothe preferred embodiments, and it will be obvious to those skilled inthe art that various changes and modifications may be made withoutdeparting from the spirit and scope of the present inventions. Forexample, in other embodiments, one or more functions performed by module10 may be implemented using one or more processors, or one or moresoftware. Also, in alternative embodiments, module 10 needs not performall of the steps in FIGS. 2-5. For example, in other embodiments, module10 does not perform Step 30, but receives a result of an analysis from asource. In such cases, based on the received result, module 10 thendetermines whether to take preventive action (Step 28) or to continuepassing data to receiver 13 (Step 32). The specification and drawingsare, accordingly, to be regarded in an illustrative rather thanrestrictive sense. The present inventions are intended to coveralternatives, modifications, and equivalents, which may be includedwithin the spirit and scope of the present inventions as defined by theclaims.

1. A computer-implemented method for processing network traffic data ina gateway device for a computer network, the method comprising the stepsof: receiving a packet; identifying whether the packet complies with aprotocol having a retransmission protocol; responsive to the packetcomplying, determining whether the packet is a previously dropped packetthat is being retransmitted according to the retransmission protocol;and dropping the packet responsive to the packet not being aretransmission of a previously dropped packet.
 2. The method of claim 1,further comprising: forwarding the packet as safe responsive to thepacket being a retransmission of the previously dropped packet.
 3. Themethod of claim 1, further comprising: flagging the packet aspotentially unsafe or as unsafe, responsive to multiple packets beingdropped and of a certain characteristic in common.
 4. The method ofclaim 1, further comprising: flagging the packet as potentially unsafeor as unsafe, responsive to multiple packets being dropped and of acertain characteristic in common.
 5. The method of claim 1, furthercomprising: flagging the packet as part of a flooding attack, responsiveto multiple packets being dropped and of a certain characteristic incommon.
 6. A non-transitory device-readable storage medium including aset of instructions stored thereon which when executed by a processor ofa device, performs a method for processing network traffic data in agateway device for a computer network, the method comprising the stepsof: receiving a packet; identifying whether the packet complies with aprotocol having a retransmission protocol; responsive to the packetcomplying, determining whether the packet is a previously dropped packetthat is being retransmitted according to the retransmission protocol;and dropping the packet responsive to the packet not being aretransmission of a previously dropped packet.
 7. The device-readablemedium of claim 6, wherein the method further comprises: forwarding thepacket as safe responsive to the packet being a retransmission of thepreviously dropped packet.
 8. The device-readable medium of claim 6,further comprising: flagging the packet as potentially unsafe or asunsafe, responsive to multiple packets being dropped and of a certaincharacteristic in common.
 9. The method of claim 1, further comprising:flagging the packet as part of a flooding attack, responsive to multiplepackets being dropped and of a certain characteristic in common.
 10. Agate way device having at least some hardware for processing networktraffic data for a computer network, the method comprising the steps of:a processor; a network interface; and a memory device, storing: a firstmodule to receive a packet; a second module to identify whether thepacket complies with a protocol having a retransmission protocol; athird module to, responsive to the packet complying, determine whetherthe packet is a previously dropped packet that is being retransmittedaccording to the retransmission protocol; and a fourth module to dropthe packet responsive to the packet not being a retransmission of apreviously dropped packet.